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Abstract. We consider type inference for guarded recursive data types 
(GRDTs) - a recent generalization of algebraic data types. We reduce 
type inference for GRDTs to unification under a mixed prefix. Thus, we 
obtain efficient type inference. Inference is incomplete because the set of 
type constraints allowed to appear in the type system is only a subset 
of those type constraints generated by type inference. Hence, inference 
only succeeds if the program is sufficiently type annotated. We present 
refined procedures to infer types incrementally and to assist the user in 
identifying which pieces of type information are missing. Additionally, 
we introduce procedures to test if a type is not principal and to find a 
principal type if one exists. 

1 Introduction 

Guarded recursive data types (GRDTs) XCC03] were introduced by Xi, Chen 
and Chen as generalization of algebraic data types. The novelty of GRDTs is that 
we may include type equality assumptions to refine types on a per constructor 
basis. Thus, we can type more programs. 

Example 1. The following data type ensures type correct construction of a simple 
expression language. Note that we make use of Haskell-style syntax in examples. 

data Exp a = (a=Int) => IsZero I (a=Int) => IsSucc (Exp Int) 

I forall b c. (a=(b,c)) => Pair (Exp b) (Exp c) 
eval : : Exp a -> a 
eval Zero = 

eval (Succ e) = (eval e) + 1 

eval (Pair x y) = (eval x, eval y) 

In contrast to algebraic data types we may refine the type of a GRDT depending 
on the particular constructor. E.g., IsZero has type Exp Int whereas Pair 
(IsSucc (IsZero 0) (IsZero 0) has type Exp (Int, Int). At first look it may 
be surprising that eval has type Wa.Exp a — > a. Consider the first clause. We 
assume that Zero has type Exp a where we temporarily make use of a = Int. 
Hence, we can give the type a. Note that we make use of polymorphic recursion, 
see the third clause. 



The idea of GRDTs dates back to Zenger's index types |Zen99| . He introduces 
a variant of the Hindley/Milner system where types ranging over indices can be 
refined for each constructor. Variants of G RDTs have been studied by a number 
of authors |CH03IJWW 04 SP04a SP04b] whereas inference has received so far 
little attention. We are only aware of the work by Simonet and Pottier SP04b 
and Peyton- Jones, Washburn and Weirich JWW04 . Simonet and Pottier es- 
tablish some sufficient conditions under which type inference can be reduced 
to some tractable constraint solving. Essentially, they demand that every poly- 
morphic recursive function and every use of a GRDT must be annotated. A 
similar approach is pursued by Peyton- Jones, Washburn and Weirich |JWW04j . 
In general, it is acceptable practice to demand some form of user-provided type 
information to support tractable type inference. This may be in particular cru- 
cial in case of polymorphic recursion Hcn93 . GRDT programs make often use 
of polymorphic recursion. Hence, there is no hope to obtain complete type in- 
ference for GRDTs unless we provide type annotations. However, we would like 
to minimize the amount of user-provided annotations and if possible provide 
feedback to the programmer which pieces of information are missing. 

In this paper, we propose several novel strategies to support inference for 
GRDTs. In summary, our contributions are: 

1. We introduce an efficient inference method for GRDTs based on a translation 
from program text to constraints where constraints are solved by unification 
under a mixed prefix. In case of (potentially polymorphic) recursive func- 
tions, we present a refined procedure which allows to supply inference with 
partial type information (Section [3J|. 

2. We give a sufficient criteria under which constraint solving is guaranteed to 
succeed. Failure of the criteria may provide useful feedback to the program- 
mer which type information must be user-provided (Section |2J. 

3. We introduce a method to construct solutions out of the individual results 
from successful sub-branches (Section EJ. 

4. We give an efficient but incomplete procedure to test if a type is not prin- 
cipal. Under some assumptions, we give a method to infer a principal type 
(Section if one exists. 

Proof sketches of our results can be found in the Appendix. 

We assume the reader is familiar with the concepts of substitutions, most 
general unifiers (m.g.mu.), unification under a mixed prefix, skolemization and 
the basics of first-order logic. We refer to LMM87 Mil92 Sho67 for more details. 

2 Guarded Recursive Data Types 

In this section, we define the set of well-typed expressions. 

Expressions e ::= K \ x \ Xx.e e e | (e :: C t) | rec/in e | case e of [pi — > e^i^i 
Patterns p x (p,p) K p Types t ::= a | t — > t | T i 

Constraints C ::= t = t \ C A C Type Schemes a ::= t | Va.C => t 

For simplicity, we omit let-definitions but may make use of them in examples. 
We consider pattern matching syntax as syntactic sugar for case expressions. 
GRDT definitions have been preprocessed and are recorded in some initial type 
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C, r h e : t (x: Va.C" ^ t) £ T 

(Eq) C D t = t' (Var-x) C D [Va]C (Rec) ' J ' ' 



C,T h e : t' C.fhi: [t/a]£ 



-T h rec/ in e : t 



/ * i \ C,r.x:ti^e:t 2 . . . C, T h e a : i 2 -> t C,T h e 2 :t 2 

(Abs) (App) — 

C, i r A:r.e : ti — > t 2 G,J h ej 62 :i 

crhe . (i P : *i 1- V5.(£>_l r,) 

(Case) C,rhp, J« : tl U for > £ / (Pat) ^ £ j£ » = ^ 



C, r h case e of [p$ — ► ei] ieI : t 2 



C, r h p -> e : t% -»• i 2 



, C 2 ACi,r h e:t MC 2 ,r )nfv(Ci,t ) = ,„ T , . , lr 
Annot) — , , (Pat-Var) i:(h (True {x : t}) 



(Pat-Pair) 
(Pat-K) 



pi : fi h Vbi.(Di I r pi ) p 2 : t 2 h V6 2 .(J>2 I T P2 ) 
(pi,p 2 ) : (ti,t 2 ) h Vbi,6 2 .(-Di AD 2 lr pi ur M ) 

K :\/a,b.D a bHa = p : [t/a]i h V6'.(-D' I T p ) 

Kp:TiV- W,b.(D' A [t/a]£> I T p ) 

Fig. 1. Typing Rules 



environment. E.g., we find that IsZero : Va.a = Int Exp a S /^n-tt etc. for 
the GRDT from Example □ 

In Figure n we define the set of well- typed GRDT programs in terms of typ- 
ing judgments C,E h e : t. Rules (Abs), (App) and (Rec) are standard. In rule 
(Eq) the side condition C D t\ = t 2 holds iff (1) C does not have a unifier, 
or (2) for any unifier <f> of C we have that 4>(ti) = 4>(t2 ) holds. Hence, we can 
change the type of an expression given some appropriate type assumptions. In 
rule (Var-x) we build a type instance of a type scheme. Rule (Case) is stan- 
dard again. Rule (Annot) deals with type annotation. Note that we only allow 
for closed type annotations, i.e. the set of variables appearing in the type and 
constraint component is assumed to be universally bound. We consider this is a 
non-essential restriction and leave the extension to "open" annotations for future 
work. W.l.o.g., we assume that there are no name clashes with other variables 
in the typing judgment. Rule (Pat) is interesting. We type the body of a pattern 
clause under the additional constraints arising out of the pattern. Note that we 
make use of an auxiliary judgment p : t h V6.(-D I F p ) which establishes a relation 
among pattern p of type t and the binding F p of variables in p. Variables b re- 
fer to all "existential" variables. Logically, these variables must be considered as 
universally quantified. Hence, we write Vb. The side condition bnfv(C, F, t 2 ) = 
prevents existential variables from escaping. In rule (Pat-Pair), we assume that 
there are no name clashes between variables 61 and b 2 . Constraint D arises from 
constructor occurrences in p. 

In contrast to standard Hindley/Milner, the GRDT system as presented does 
not enjoy principal types. 

Example 2. We assume a primitive operation (+) : : Int->Int->Int. 
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data Erk a = (a=Int) => I a I (a=Bool) => B a 
f x y = case x of I z -> y+z 

We find that Va.Erk a — > Int — > Int, ^a.Erk a — > a — > Int, Wa.Erk a — > a — > a, 
\/b,c.Erk {Int — > Int) — > 6 — > c, "ib,c.Erk {Bool — > Boo^) — > & — > c, are all 

incomparable types but there does not seem to be a most general type. Note 

that the last set of types is correct. We temporarily make use of False (which 

is equivalent to e.g. Int = Int — > Int) under which we can give any type to the 

body of the case expression. As pointed out in jCHOSj such "meaningless" types 

can safely be omitted. In essence, the program text belonging to a meaningless 

type represents "dead code" and can always be replaced by _L : Va.a. Note that 

meaningless types will always destroy the principal types property. Hence, we 

will rule out such types by strengthening rule (Eq). We drop the first condition 

and only impose the second condition that for any unifier of C we have that 

<j){t\) = 4>{t2) holds. Note that the first three types are "meaningful" but there 

is still no most general type. 

The potential loss of principal types for GRDTs has already been observed 
by Cheney and Hinze |CH0 .^ . As a solution they suggest explicitly providing 
result-type annotations for case expressions. However, the above example shows 
that this is not sufficient to retain principal types. As shown by Simonet and 
Pottier |SP04b| . we can trivially achieve principal types by enriching the set 
of constraints allowed to appear in typing judgments. E.g., we can give f the 
non-expressible "principal type" Va,t y ,t.{a = Int D {t y = Int A t = Int)) => 
Erk a —> t y —> t. Notice the use of Boolean implication (d) to describe the set 
of types which can be given to f . There are several good reasons why we do not 
want to admit such expressive types. For example, type inference becomes more 
complex, and types become less readable. 

3 Efficient Type Inference 

We introduce an efficient inference method for GRDTs which is divided into two 
steps. In a first step, we take the standard route and generate an appropriate set 
of constraints out of the program text. For this purpose, we assume an enriched 
constraint language consisting of Boolean connectives such as D (implication) 
and quantifiers V and 3. If necessary we refer to "simple" constraints as the set 
of constraints admitted in the type system described in the previous section. 
In the second step, we perform some equivalence transformations on constraints 
such that resulting constraints can be solved efficiently by unification under a 
mixed prefix |Mil92| . 

In Figure^ we describe the constraint generation rules in terms of judgments 
r, e \~w {F 1 1). We commonly refer to F as the inferred constraint. Notice the 
use of Boolean implication (d) and universal quantification (V). In rule (Pat), 
we use 3y-F as a short-hand for 3fv{F) — V.F. 

Example 3. Consider constraint generation for Example [21 where Fi n n — {I : 
Va.a = Int =>• a — > Erk a, B : Va.a = Bool =>• a — ► Erk a}. Let e = 
A. x. Xy. case x of / z — > {y + z) (desugared version of f 's program text). Then 
0, e ^ w (t x = Erk a A (a = Int D {t y = Int A ti = Int)) I t x — ► t y — > tx). Note 
that we have slightly simplified the constraint and type. Often, we "normalize" 
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nT , (x :Va.C =>• t) € r ,_, , r.f:ti,e \- w (Fife) afresh 

(Var-x) . - — (Rec) — ; ; — — 

r,x\- w {C\t) r,rec/in e h w (F,ti =t 2 I ti) 

r,ei h w (Fi Hi) 

. a tresn 

z * \ F, e 2 h ff (F 2 1 1 2 ) , . . „,|.v 

(App) tfresh F.fiAftAi^^i (Ab8) F.*:a,eh w (Flt) 



r,ei e 2 h w (Fit) 



F,Aa;.e h w (F I a -> t) 



r,pi a h w {Fi \ Q for i e / F,e h ff (F e I t e ) h,t 2 fresh 

(Case) F = F e A ti = te ^> A Aj 6 j(F Ati = tj) 

F, case e of [p* — > ei]jgj (F 1 t 2 ) 

p h Wb.(D \r p \ti) rur p ,e h w (F e I t e ) t fresh 
(Pat) F = Vb.(F> D 3 far ^ te) .F e ) A t = ti -> t e 

r,p^e \- w (FN) 

F,e h (F'lf) a = MC,t) 

(Annot) FEVa.((CAt^)D3 f J') (Pat-Var) - f 

> i ; , a; r (i rue : t[ r) 

F, (e :: (C £)) (F 1 1 ) V 

(Pat Pair) Pi H VbT.(J>i I F P1 jUi) p 2 h VMI> 2 I F P2 1 fe) 

(pi,p 2 ) h V&iTM-Di A F> 2 I F P1 U r Pl I (ti.fe)) 

• Wn (if 

(Pat-K) 



K :\/a,b.D^>t->T a p \- W.(D' I F p I t p ) 



Kph W, b.((j>(D') A D I 0(F P ) I T <p(a)) 
Fig. 2. Generating Constraints 



the resulting type and constraint and write 

t = t x — > t y — > ti, f x = -Erfc a, (a = 7n£ D (ty = Irrf, £i = Int)) 

where t refers to the type of expression e. 

The important observation is that based on the following first-order equiva- 
lences we can normalize constraints: (1) (Fi D Qa.Fa) <-> Qa.(F\ D F2) where 
a g yv(Fi) and (2) (Q0.F1) A (Q6.F a ) <-> Qa,b.(Fi A F 2 ) where a fv(F 2 ), 
b fv(Fi) and Q e {3,V} and (3) d D (C 2 D C 3 ) (Ci A C 2 ) D C 3 . We ex- 
haustively apply the above identities from left to right. W.l.o.g., we assume that 
bound variables have been renamed. We can conclude that each inferred con- 
straint F can be equivalently represented as Q.Co A {D\ D C\) A ... A (D n D C„) 
where Co, D%, Ci,...,D n ,C n are constraints and Q is a mixed-prefix of quanti- 
fiers of the form VaT3bi...Va^3b n . Commonly, we refer to the last constraint 
as the normalization of F. Normalized constraints can be efficiently solved by 
unification under a mixed prefix as follow: (1) Build an m.g.u. 4> of Co under 
prefix Q (see |Mil92| for details on unification under a mixed prefix), and (2) 
set Fj = 4>i o 4>{Ci) if m.g.u. <f>i of 4>{Di) under prefix Q exists, or Fj = True 
otherwise for i = 1, ...,n. (3) Build the m.g.u. ijj of Co A E\ A ... A F„ under 
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prefix Q. In case all three steps were successful, we write ip = solve(F). Note 
that in such a situation, we find that ip is a solution of F, i.e. (= ^p{F) holds. We 
write Fx |= F2 to denote that any model of Fi is a model of F2. Fi is commonly 
omitted if True. 

Example 4. Consider the constraint generated in Example^ In solving step (2), 
we generate t = t x — > t y —> ti,t x = Erk a,(t y = Int, fa = Int). Hence, we 
find the solution ip = [Int/t y , Int/ti, Erk a — > Int — > Int/t]. Hence, expression 
A. x. Xy. case x of / z —> (y + z) can be given type Wa.Erk a — > Int — > Inf. 

Note that the inferred type is not principal. See the discussion in the previous 
section. Hence, the question is whether this type is acceptable. We will address 
such issues and how to check for principality in Section The least we can state 
at this stage is that our inference method is sound. 

Theorem 1 (Soundness of Inference). Let r an environment, e an expres- 
sion, F a constraint and t a type such that F,e \~w {F I t). Let tp = solve(F). 
Then True,ip(r) h e : tp(t). 

There are cases where our method fails, although the program is well-typed. 

Example 5. Here is an example taken from [CH03 . 

data R a = (a=Int) => RInt I forall b c.(a=(b,c)) => RProd (R a) (R 
size RInt = 1 

size (RProd a b) = (size a) + (size b) 

We generate the (simplified) constraint t = R a — > t\,{a = Int D fa = 
Int),vb,c.(a = (b,c) D t = R b — > t2,t = R c — > t^,ti = t2,fa = ts,ti = Int). 

Normalization yields (V6, c.(t = R a — > fa, (a = hit D fa = Int), (a = (b,c) D 

t = R b — > t 2 ,t — R c — > t 3 ,ti — t 2 ,t 1 — t 3 ,ti — Int)). 1 In the solving step 

(2), we generate t = R a —> fa,fa = Int,R (b,c) = R b, R (b,c) = R c,fa — 

t 2 ,ti = ^3, fa = Int which cannot be solved by unification under the prefix V6, c. 

However, size is well-typed under type Vo.i? a — > Int. 

Example 6. We consider a variation of Example [21 Additionally, we make use of 
a primitive operation (&&) : : Bool->Bool->Bool. 

f (I x) = x + 1 

f (B x) = x kk True 

We_ generate t = Erk a — ► fa, (a = Int D fa = Int), (a = Bool D fa = Bool). In 
solving step (2), we generate t = Erk a — ► fa, fa — Int, fa — Bool which is not 

solvable. Hence, our inference method fails. On the other hand, f can be given 

type \/a.Erk a — > a. 

We draw the following conclusions. Our inference method may fail because 
GRDT programs often make use of polymorphic recursion (see ExampleEJ. An- 
other reason for failure is that we naively combine the inference results from dif- 
ferent branches (see Examplc|nj|. Indeed, other inference approaches SP04b JWW04 

1 We silently drop the outermost "empty" forall quantifier and the existential quantifier 
over t. 
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face the same problem. Hence, we will need to sufficiently annotate the program 
such that inference succeeds. It should be clear that we must provide types for 
polymorphic recursive functions. The problem is shown to be undecidable for 
Hindlcy/Milncr Hen93 . However, instead of providing full annotation we would 
like to provide only a minimal amount of information. E.g., in case of the size 
function it is sufficient to provide only information about the input type. 

Example 7. Recall Example [S] We guess that size must take in values of type 
R a — > b for any a and for some b. The programmer could indicate this infor- 
mation via "partial" annotations of the form size: :R a->_. For type inference 
purposes, we simply assume that size has type Va, b.R a — > b. Under this as- 
sumption, we generate the (simplified) constraint t = R a — ► ti, (a = Int D t\ = 
Int),\/b, c.(a — (b,c) D t\ = Int). Our solving method succeeds here and yields 
that size has type Va.i? a — > Int. 

In general, we propose the following refinement of rule (Rec) . 

r.f : a,e \~w (F I £2) guess a type a ip = solve(F) 
(Rec-Guess) a = fv^{t 2 )) - fv{j>{F)) ^(r).f : Va.y>(t 2 ),e h w (F' 1 1' 2 ) 
r, rec/ in e h w (F,Va.(ip(t 2 ) =t' 2 D F') \t 2 ) 

Note that we also have to check that the result we obtain from guessing is indeed 
a valid type. That is, we first build the type a 1 = Va.V'fe) and perform inference 
again. Then, we verify that the type inferred, represented by (F 1 I t' 2 ), under 
assumption / : a 1 subsumes a' . The constraint Wa.^ipfo) = t' 2 D F') guarantees 
that this condition holds. Note that a similar idea has been mentioned in GL02 . 

Obviously, this refined method requires that we have a good heuristic for 
guessing types. We argue that in many cases we can guess from the program 
text alone which "input" , i..e. lambda-bound, variables are connected to GRDTs. 
See Examples n and However, the upcoming Example I1UI shows that this is 
not necessarily the case. Lambda-bound variables may be connected via type 
constraints to GRDTs. For such cases, we simply introduce a fresh universal 
variable. Note that we can further refine our method by performing a couple of 
iterations. In particular, this helps if Va.a is our initial guess. 

Note that the refined method will not succeed in case of Example Q] (if we 
guess that eval has type \/a,b.Exp a — > b). The problem here is that the type 
changes for each branch (the same happens in Example^} . Our inference method 
still naively combines the results from different branches. Hence, we fail. Further 
refinements of our inference scheme are necessary. In Section we show how 
to build solutions automatically by inspecting sub-results of inference. In the 
next section, we first establish a criteria under which constraint solving always 
succeed. Failure of the criteria may prove helpful to assist user-guided input in 
terms of type annotations such that inference succeeds eventually. 

4 Constraint Solving Criteria 

The observations in the previous section let us conclude that inference may fail 
because types change in different branches (assuming that we exclude the event 
of a type error) . We are looking for a sufficient criteria under which we can guar- 
antee that inference will succeed. In case the criteria cannot be satisfied, the 
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hope is that we obtain some crucial information to identify which type informa- 
tion is missing such that inference might succeed. Our task is to identify all type 
equations arising out of different branches which may lead to some inconsisten- 
cies. Looking at this question from a different angle, we need to identify which 
types must be known such that no inconsistency will arise. For this purpose, 
we keep track of types which are "known" . We introduce a predicate known(t) 
which states that type t is known. E.g., type t is given through an annotation. 
However, we may also implicitly propagate known types. E.g., assume inference 
generates the constraint t = (ii,*2) then we conclude that also t\ and t% are 
known. We can capture this via the following relations. 

Vii, t2-{known(t\ — > £2) known{t\) A knownfo)) 
Vij., t2-(known((ti , £2)) <->• known{ti) A knownfo)) 

Note that a type must be known if the different branches disagree. Assume 
E t denotes the equations constraining t from a particular branch. Then, the 
constraint known(t) V E t expresses the fact that t is known or the constraints in 
E t will become effective. Let's focus on two branches and observe the effect on 
t. We find the constraint (known(t) V E t ) A (known(t) V E' t ) which is equivalent 
to (known(t) V (E t A E' t )) (2). Assume the two branches have the same effect on 
t. E.g., this is the case for t\ in case of Example Then, (2) is equivalent to 
Et,E't indicating that <i must not be known necessarily. On the other hand, in 
case of Example [H] the branches disagree. Hence, (2) is equivalent to known(ti) 
indicating that t\ must be known. 

We incorporate this idea of identifying which constraints must be known into 
our constraint generation rules. We adapt rule (Pat) from Figure |21 as follow: 

p h Vb.(D I r p I ti) rur p ,e \- w (F e H e ) t fresh a = fv(F e ) 

(Pat) F = yH{D D ^fiXr,i,t.y F °) A 1 = "> ^ A 

/\ aea (known(a)V(3fv(D,F e )-fv(r,a,b).(DAF e ))) 

r,p^e ^ w (Fit) 

For simplicity, we only consider expressions e which do not contain nested case 
expressions, hence, F e is a simple constraint. Otherwise, we will need to manip- 
ulate the program text by introducing auxiliary (local) function definitions and 
"flattening" the program by performing lambda-lifting. 

In addition to the existing normalization steps we make use of the following 
identities: (Fi VF 2 ) A(fi VF 3 ) «-► (Fi V(F 2 AF 3 )) and (FiV3a.F 2 ) «-► 3a.(FiVF 2 ) 
where a ^ fv(Fi). Hence, the constraint resulting out of e is now of the form 
Q.Cq A (Di D Ci) A ... A (D n D C n ) A K where Co, A and d consist of 
conjunction of equations and K is equivalent to f\ a {known(a) V E a ) where E a 
is a conjunction of equations constraining a. 

The main point of our formulation is that we now can query the normalized 
constraint to identify which types must be known. 

Example 8. Here is a variation of Example|B]where we make use of (>) : : Int->Int->Bool. 

h (I x) = x > 1 

h (B x) = x kk True 
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The normalized constraint generated out of the program text is as follow. We 
denote this constraint by F. 

t = Erk a^tih (known(ti) V (h = Bool A*i = Bool) (C A K) 

(a = Int Dh = Bool) A (a = Bool D t x = Bool)) {(D x D d) A (D 2 D C 2 )) 

We find that F \£ known(ti) . That is, ii need not be known. Hence, we can safely 
combine the results from different branches. Hence, inference succeeds. Indeed, 
we infer that h has type Va.Erk a — > Bool. Note that a similar reasoning applies 
to Example [7] 

More formally, we define IC(F) — {known(a) \ F |= known(a)}. Silently, we 
assume that the known relations described in are always included. Note that 
for a given a we can decide F \= known(a) by putting F, -iknown(t) into clause 
form and test for a contradiction by applying resolution. Note that resolution is 
complete for refutation (see e.g. jSHo67])- Hence, we have a decidable check to 
verify if inference is successful. 

Lemma 1 (Constraint Solving Criteria). Let e be an expression containing 
no annotations and no nested case expressions. Let Q.Cq A {Dx D C\) A ... A 
(D n D C n ) A K be the (normalized) constraint generated and t the type of e. 
Let U be a (simple) user-provided constraint where Kjj = A ae ^ u ^known(a) . If 

K{U AKuAQ.CoAiDi D d)A...A(D n D C n )AK) = K.{U AK V AQ.C A{D x D 
C\) A ... A (D n D C n )) and U A Q.C A (D x D C x ) A ... A (D n D C n ) is satisfiable, 
then U A Q.Cq A (D x D C\) A ... A (D n D C n ) has a solution. 

The above lemma suggests the following strategy. By default always perform 
efficient solved form inference. In case we fail, pick a t and check whether t 
must be known. The question of guessing an appropriate t is non-trivial. The 
"shape" of t is constrained by the variables and equations generated. Hence, 
there is only a finite number of non-trivial known(t). However, enumerating all 
possibilities might be infeasible in practice. A good guess might be to consider all 
variables involved in a minimal unsatisfiable subset (e.g. |SSW03j ) of constraints 
in Co A E x A ... A E n . 

Example 9. Recall Example El In an intermediate step, we attempt to solve 
t = Erk a — ► ti,t x = Int, t\ = Bool which fails. We find that t\ — Int, t\ = Bool 
form a minimal unsatisfiable subset. We pick a variable from this set (there's 
only one here). The (normalized) constraint generated via the "known" inference 
approach is as follow, t = Erk a — * t%, (a = Int D t\ = Int), (a = Bool D t\ = 
Bool), (known{t\) V (ti = Int,t\ = Bool). Immediately, we find that known{t\) 
is a logical consequence. The user did not provide any information about t\, 
hence, we conclude that t\ must be provided such that inference succeeds. E.g., 
we find that if the user provides t\ = a the conditions of the above lemma are 
fulfilled. Indeed, efficient inference succeeds now. 

A similar reasoning applies to Example ^ Here is another interesting exam- 
ple. 

Example 10. Consider the following program where we make use primitive func- 
tions hi: :Erk Int->Int->Int, h2 : :Erk Bool->Bool->Int and h3 : :a->a->Bool. 



9 



f = \y -> \x -> (h3 y x, — (1) 

case y of I z -> hi x z — (2) 
B z -> h2 x z) — (3) 

We generate the following constraint 




(0) 
(1) 
(2) 
(3) 



ty = t x ,t2 = Bool, 

(t z = Int D t z = Int, t x = Erk Int, t% = Int), 

(t z = Bool D t z = Bool, t x — Erk Bool, t± — Bool) 

(known(t x ) V (t x = Erk Int, t x = Erk Bool) 



Note that no user annotations are provided and the type of x changes. We have 
seen previously that this is may make our inference method fail (see Examples ^ 
and [(J). However, efficient inference succeeds, i.e. solving of constraints (0-3) 
yields a solution, and we can formally show why. We can argue that the type of 
y is known because the case expression forces y to be a GRDT Erk a. Hence, we 
add the fact that known{t y ) . In combination with constraint (1) we can establish 
that the assumptions of Lemma ^ arc satisfied. 

5 Incremental Building of Solutions 

Instead of immediately solving constraints generated by Figure or in case of 
failure trying to find which types must be known as suggested in Section 
we show how to build solutions incrementally. We illustrate our approach by 
example first. 

Example 11. Consider a variation of Example 

data Erk a = (a=Int) => I a I (a=Bool) => B a 
h = Ax. Ay. case x of I z -> z + y 

B z -> z kk y 

We generate the following constraint. 



Note that inference fails here. Instead, for each Co A D D C we calculate S = 
{E | Co A D A C D E} where E is a conjunction of equations, i.e. the set of all 
implied equations which potentially take part in a solution. We find that 



<5i = {{t y = Int} , {t y = a} , {t r = Int} , {t r = a} , 
{t y = Int, t r = Int} , {t v = Int, t r — a} , 
{t y — a, t r — Int} , {t y — a, t r — a}} 

$2 = {{t y — Bool} , {t y — a} , {t r = Bool} , {t r — a} , 
{t y = Bool, t r = Bool} , {t y — Bool, t r — a} , 
{ty = a, t r = Bool} , {t v = a,t r = a}} 



Then, we go through all combinations Si £ Si and 5*2 £ 52 to find a solution. 
Note that there can only be a finite number of combinations. E.g., S = {t y = 
a, t r — a} is such a solution. As we will see later, this solution is even principal. 
Hence, h has the principal type \/a.Erk a — > a — > a. 



t = Erk a — > t y — ► t r A (Co) 

(a = Int D (t y = Int A t r = Int)) (D 1 D d) 

(a = Bool D (t y = Bool A t r = Bool)) (D 2 D C 2 ) 
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Note that the above method applied to Example 2] would e.g. infer the type 
Va.Erk a —> a. The important observation is that for satisfiable equations under 
a mixed prefix we can enumerate all implied equations. We define S(F) = {E | 
F D E,E consists of equations only}. 

Lemma 2 (Finite Solutions). Let Q.C be a satisfiable set of equations under a 
mixed prefix Q. Then, S(Q.C) is finite (assuming a canonical form of equations) 
and each element consists of only a finite number of equations. 

The following lemma shows that we can construct a solution out of the 
implied constraints resulting from the different branches if the solution space 
is non-trivial (i.e. does not only contain False). For convenience, we define 
Et/> — [a, — ip(a) | a <E domain(ip)} to be the constraint representation of a 
substitution tp. 

Lemma 3 (Building Solutions). Let Q.C A (D x D C x ) A ... A (D n D C n ) be 

such that ip is a solution and Q.Cq AAA Ci is satisfiable for i — 1, ... n. Then, 
there exist Si 6 S(Q.Cq A Di A Ci) for i ~ 1, .., n such that E^ and f\ i=1 n Si 
are equivalent w.r.t. fv(Q.F). 

6 Principal Types 

In Example|2]we have observed that the GRDT system does not enjoy principal 
types in general. Given the complexity of type inference for GRDTs we are quite 
content to infer a type. However, if possible we would like to report to the user 
if a type is not principal. In this section, we identify a a necessary criteria for a 
type to be principal. Hence, we obtain an efficient but incomplete procedure for 
testing if a type is not principal. Based on the enumeration technique given in 
the previous section we can even find a principal type. We simply consider all 
combinations of possible solutions and check if there is a principal solution. 

First, we define principal solutions. We say tp is a principal solution of F iff 
|= ip(F) and given another solution <p of F we have that 39. <p — 9oip. That is the 
substitution ip is more general than any other solution. It is easy to show that 
every principal solution yields a principal type. Every principal solution must 
satisfy the following criteria. 

Lemma 4 (Necessary Principal Solution Criteria). Let ip be a principal 
solution of F. Let F' be the skolemized version of F of the form Co, (D\ D 
C x ), ...,(£>„ D C n ). Then, {E^, C , A i= i,...,n A) ~ (Co, Ai=i,...,„(Ci, A)) where 
E^ — {a = 4>{a) | a G domain(ip)} . 

An interesting observation is that "meaningless" types are never principal. 

Example 12. Recall the constraint generated out of f 's program text (see Ex- 
ample |2l 

t = t x — > t y — > t\,t x — Erk a, (a = Int D (t v = Int, t\ — Lnt)) 

The meaningless type yb,c.Erk (Int — » Int) — » b — > c from Example corre- 
sponds to the solution ip — [Erk (Int — * Int) — > b — > c/t]. We omit skolemization 
which is unnecessary here. We find that the lhs of the logical condition is unsat- 
isfiable (since (p(a) = Int — > Int) whereas the rhs is. Hence, ip is not principal. 
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The above applies to all meaningless types. A silent assumption is that con- 
straints appearing in the types of GRDT constructors K are always satisfiable. 
Furthermore, we need to rule out the case that the program is free of type errors. 2 

Unfortunately, our (necessary) principal types condition seems to weak in 
practice to identify non- principal types. In Example |2 we argued that f has no 
principal type. However, we find that types Va.Erk a — > Int — > Int, Wa.Erk a — > 
a — > Int and \fa.Erk a — > a — > a (respectively the solutions from which they 
were derived) do satisfy the above criteria. Hence, we cannot verify that they 
are not principal. 

Instead, of checking for principality we simply compute all possible types and 
check if one of these types is principal. Our method is as follows. Let Q.CqA(Di D 
C\) A ... A {D n D C n ) be a normalized constraint generated out of expression e. 
First, we check that Q.Cq ADjACj are satisfiable for i — l,..,n (we simply build 
the m.g.u. under prefix Q). If not then either expression e has a meaningless 
type annotation or contains a type error. Note that the type error may be due 
to our limited inference scheme. E.g., the constraints generated from Example^] 
via the rules Figurehead to an unsatisfiable constraint although the program is 
well-typed. Clearly, we need to report an error in such a situation and hope for 
further user input. Otherwise, based on Lemma[2]we compute the sub-solutions 
S(Q.Cq A Di A Ci) for i = 1, ..,n and compute via Lemma |3] all combinations 
which yield a solution. Note that there can only be a finite number of solutions. 
Hence, we can test whether any of these solutions is principal. 

We can state the following result . 

Theorem 2 (Principal Types GRDTs). We can infer a principal type for 
GRDTs if one exists and constraints generated out of the expression are satisfi- 
able. 

Note that based on our refined inference scheme in Section 0] in combination 
with our method for building solutions we find that function size in Example^! 
has types Va.i? a — > Int, Va.i? a — > a but none of the two is principal. Note that 
R Int — > Int is a meaningless type. On the other hand, we find that eval in 
Example ^has the principal type Va.Exp a — > a. 

7 Conclusion and Related Work 

To our knowledge, there are only two previous works which study type inference 
for GRDTs. The approach by Simonet and Pottier |SP04bj uses the same ab- 
straction from program text to constraints in the first step of type inference. They 
demand a sufficient number of type annotations such that solving is tractable. 
In contrast, we could show that solving is always tractable by reduction to uni- 
fication under a mixed prefix. We believe that our inference scheme will succeed 
for all programs which are successful under their scheme. They seem to imply 
that sufficient type annotations ensure that solving is tractable and solving is 
successful. However, we can never rule out the event of a type error. 

The goal of the work by Peyton-Jones, Washburn and Weirich |.IWW 04 
is to make type inference "predictable". 3 The gist of their work is to impose 

2 Remember that with a meaningless type we can even type ill-typed programs because 
under the False assumption we can give any type to an expression. 

3 We would like to point out that no type inference system is ever predictable due to 
(unavoidable) type errors in user programs. 
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the condition that if the type of the body of a pattern clauses changes due to a 
GRDT, then the GRDT must be explicitly provided by the programmer. Clearly, 
this condition is motivated by the fact that in a conservative inference scheme 
we combine the results from the individual branches. Hence, we may fail unless 
types are explicitly provided. However, they rule out Example II Ul which we have 
seen carries enough type information such that inference succeeds. 

In this paper, we have introduced several improved inference methods for 
GRDTs for guessing the types of GRDT programs (Section|3J), identifying miss- 
ing information based on the efficient inference criteria (Section^) and building 
solutions via enumeration (Section EJ. In combination, these methods allow us 
to infer the types of all examples in this paper. Furthermore, we are the first to 
discuss extensively the issue of principal types. We have presented novel methods 
to check if a type is not principal type and to find a principal type if one exists 
(Section EJ). 

In future work, we plan to investigate how our type debugging methods SSW03 
developed for Hindley/Milner typable programs can be adapted to the GRDT 
setting. 
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A Proofs 

A.l Proof of Theorem IT1 

Our assumptions are: Let r an environment, e an expression, F a constraint and t 
a type such that T, e \- w (F 1 t). Let i/j = solve(F). Then True, ip(r) h e : tp(t). 

Proof (Sketch). We can easily show that F, r, h e : t assuming we extend the 
sets of constraints allowed to appear in judgments. Let N be the normalization of 
F. Skolemization is a satisfiability preserving transformation. Hence, if |= ip(N) 
then |= Tp(F). We can easily verify that judgments are closed under substitutions. 
Hence, we find that True, ip(r) h e : ^(t). 



A.2 Proof of Lemma ^ 

Our assumptions are: Let e be an expression containing no annotations and no 
nested case expressions. Let Q.Cq A (£>i D C\) A ... A (D n D C n ) A K be the 
(normalized) constraint generated and t the type of e. Let U be a (simple) user- 
provided constraint where Kjj — A al -j v ^known{a) . If IC(UAKu AQ.CqA(Di D 

d) A ... A (D n D C n ) A K) — )C{U A K v A Q.C Q A {D l D d) A ... A (£>„ D C n )) 
and U A Q.Cq A (D 1 D d) A ... A (D n D C n ) is satisfiable, then U A Q.Cq A (D x D 
C\) A ... A (D n D C„) has a solution. 

Proof (Sketch). We first consider the case that U is True. Immediately, we find 
that branches must agree. Otherwise, f\ k (a,i = t ik ) is equivalent to False. Hence, 
i<2 |= known(ai). However, by assumption we have that fC(Fi) — K(F2) and 
clearly F± ^= known(ai) (not that Kjj is True as well). Hence, branches must 
agree. Hence, Afc( a « = ^*») ^ s satisfiable. We know that the constraint problem 
is satisfiable. Hence, our efficient inference succeeds and generates a solution. 

Assume U is non-trivial. We assume the user-provided information is given 
by some type to. W.l.o.g., we compare F\ = t = t A known(t ) A (D{ D d) 
against F 2 = t = t A (D{ D d) A K where K = (known(a.i) V f\ k (a>i = t ik ). 
We ignore the prefix Q. Note that variables in to ar e universally quantified. We 
distinguish among the following two cases. 

Case: Branches disagree, i.e. type at changes. Hence, Afc( a « = ^i*) i s equiva- 
lent to False. Hence, F2 \= known(ai). By assumption /C(i*\) = JC^F?), hence, 
Oj is defined in t = to A known(to), i.e. a, G fv{to). By assumption the constraint 
generated is satisfiable. Hence, a solution of t = to A (Di D C\) exists. We 
build the m.g.u. ip of t = to. Hence, ip < <f>, i.e. ip is more general than <j). In 
particular, we have that ip( a i) ^ 4 > ( a i) (2)- We consider the efficient inference 
problem t = t^AEi. Note that <j> is a solution. Because of (2) we also have that t/j 
is a solution (for all a^s which change their types in different branches). Hence, 
efficient inference succeeds. 

Case: Branches agree. Hence, Afe( a « = tik) ^ s satisfiable. Same reasoning as 
before shows that efficient inference succeeds. 
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A. 3 Proof of Lemma |3] 

Our assumptions are: Let Q.Co A (A D C\) A ... A (D n D C n ) be such that 
ip is a solution and Q.Co A A A Ci is satisfiable for i = 1, „,n. Then, there 
exist Si S S(Q.Co A Di A Cj) for i — 1, ..,n such that E$ and Aj=i n ^ are 
equivalent w.r.t. fv(Q.F). 

Proof (Sketch). We abbreviate by S. We have that S D Q.F iff Q.S D 
Co A (S A A D Ci) A ... A (S A Ai D C„) (assuming bound variables have been 
renamed). Let V = fv(Q.F). Clearly, we have that S when projected onto V is 
contained in Ui=i,...,n <5 (2- C 'o A A A C*). 

A. 4 Proof of Lemma |4] 

Our assumptions are: Let if) be a principal solution of F. Let F' be the skolemized 
version of F of the form C , (A D Ci),...,(A n D C„). Then, (E^,,C 0> A l= i,...,„A) <-+ 
(Co, A l= i,...,„(C A)) where F^ = {a = 0(a) | a e domain^)} . 

Proof (Sketch). Note that ^ is a solution of F iff E$ D F. Note that skolemiza- 
tion is a satisfiability maintaining transformation. Hence, we can assume that 
E^ D F' (for convenience we keep the implicit universal quantifier). In the fol- 
lowing, we use S as a short-hand for E^. We have that Co, Ai=i n ^ s a so ~ 
lution. tp is principal, hence, Co,/\ i=1 n Ci D S (1). From (1), we obtain that 
Co,A l= i „(A,Cj) D S,C ,Aj=i „ A (2). ?A is a solution, hence, S, Co D 

^o,Ai=il..'„(A 3 Ci). We conclude that S,C 0) A i= i,...,„ A 3 A, : (3). 

From (2)' and (3), we obtain that (S, C , A i= i „ A) ~ (0), Ai=i 'nfe> A))- 



15 



